● 前言

延續 Day 11的Minikube 實作，今天把雲端常見的四種部署策略用最精簡的方式梳理：何時用、怎麼做、怎麼回滾。

● 四種部署策略

1.滾動部署(Rolling Update):

▪概念：一批一批替換 Pod，零停機、預設最常用。

▪適用時機：小改動、高頻率上線；新舊版本可同時存在。

▪缺點：回滾要等批次完成；務必設好 readinessProbe。

2.重新創建 (Recreate):

▪概念：先砍掉全部舊 Pod，再創建新 Pod；中間會有停機。

▪適用時機：新舊版本無法並存（如相依資源衝突）且可接受短暫停機。

▪缺點：務必安排維護視窗；檢查資料遷移是否已完成。

3.藍綠部署(Blue-Green):

▪概念：同時維持 兩套完整環境（Blue/Green），以 Service 切換流量。

▪適用時機：大改版、需快速切換/回滾、風險隔離。

▪缺點：基礎設施成本較高；共用資料時要注意 雙版本 schema 相容。

4.金絲雀(Canary):先讓少量流量走新版本，確認穩定再逐步放量。

▪概念：先讓少量流量走新版本，觀察指標穩定再逐步放量。

▪適用時機：對穩定性極敏感、需要以資料驅動控制風險。

▪缺點：需要流量治理能力（Ingress 權重、或 Service Mesh/Argo Rollouts），並配合 SLO/告警。

● 注意事項

▪health probes 一定要有：readinessProbe 防止未就緒先收流量；livenessProbe 自動自癒。

▪資料庫相容性：先做向前/向後相容的 migration；不可並存就選 Recreate 或藍綠。

▪把回滾當日常：確保每次上線都能在 1–2 指令內回滾。

● 總結

Kubernetes 的部署策略並沒有「唯一正解」，而是根據場景取捨：

▪Rolling Update → 適合大部分日常小改動。

▪Recreate → 當新舊版本無法共存時的最後手段。

▪Blue-Green → 成本較高，但能快速切換與回滾。

▪Canary → 最謹慎，也最依賴監控與流量治理。

📌 最重要的是：每次上線都要能快速回滾，這才是真正的安全網。

在 Day 11 我們已經成功把應用程式部署到 Minikube 的 Pod 中，但 Pod 本身只是「內部可見」。

👉下一篇 : 要讓外部世界能真正訪問服務，就需要 Service 與 Ingress。